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The Orion Crew Exploration Vehicle (CEV) will be the first human spacecraft 
built by NASA in almost 3 decades and will be the first vehicle to perform both 
Low Earth Orbit (LEO) missions and lunar missions since Apollo. The 
awesome challenge of designing a Guidance, Navigation, and Control (GN&C) 
system for this vehicle that satisfies all of its various mission requirements is 
countered by the opportunity to take advantage of the improvements in 
algorithms, software, sensors, and other related GN&C technology over this 
period. This paper describes the CEV GN&C reference architecture developed 
to support the overall NASA reference configuration and validate the driving 
requirements of the Constellation (Cx) Architecture Requirements Document 
(CARD, Reference 1) and the CEV System Requirements Document (SRD, 
Reference 2). The Orion GN&C team designed the reference architecture based 
on the functional allocation of GN&C roles and responsibilities of CEV with 
respect to the other Cx vehicles, such as the Crew Launch Vehicle (CLV), Earth 
Departure Stage (EDS), and Lunar Surface Area Module (LSAM), across all 
flight phases. The specific challenges and responsibilities of the CEV GN&C 
system from launch pad to touchdown will be introduced along with an 
overview of the navigation sensor suite, its redundancy management, and flight 
software (FSW) architecture. Sensors will be discussed in terms of range of 
operation, data utility within the navigation system, and rationale for selection. 
The software architecture is illustrated via block diagrams, commensurate with 
the design aspects. 


INTRODUCTION 

This paper summarizes NASA GN&C reference design architecture for the CEV, based on the Requirements 
Analysis Cycle (RAC) efforts of 2006, leading up to the Cx System Requirements Review (SRR). The purpose of 
this GN&C reference design was to assess the feasibility and correctness of the Cx and CEV requirements that drive 
CEV GN&C capabilities and to develop a sound engineering design baseline within NASA prior to prime contractor 
downselect and SRR. 

The reference GN&C architecture described within this document addresses the driving requirements, the GN&C 
roles and responsibilities of the CEV, its navigation sensor suite and redundancy management scheme, and a 
candidate flight software architecture. 

DRIVING REQUIREMENTS 

Table 1 paraphrases the key requirements from the CEV SRD that drive the need, directly or indirectly, for targeting 
and GN&C capabilities onboard the CEV. Such capabilities are presumed to be implemented via onboard flight 
software integrated with the requisite sensors and effectors to provide the accuracy and precision required either to 
meet the functional requirement or the explicitly required performance specifications. The italicized requirements 
reflect the requirements owned and updated by the Flight Dynamics (FD) team and recommended to the 
Constellation Program Office for baselining prior to Cx SRR. 


Table 1: DRIVING REQUIREMENTS ON CEV GN&C CAPABILITY 


Requirement 

no. 

Requirement 

CV0038 

The CEV return the crew to Earth during loss of communications with Earth during all mission phases. 

CV0039a 

The CEV shall provide abort capability starting on the launch pad with the arming of the Launch Abort 
System through operations in LEO. 

CV0039b 

The CEV shall provide abort capability from Low Earth Orbit to arrival in the lunar reference orbit. 

CV0049 

The CEV shall insert into LEO after being delivered to the mission-specific Earth Ascent Staging Target by 
the CLV. 

CV0052 

The CEV shall provide automated maneuvers to the CLV and to target abort landing locations. 

CV0085 

The CEV shall perform an automated deorbit maneuver from LEO. 

CV0103 

The CEV shall perform navigation for abort initiation and execution during loss of communications with 
Earth. 

CV0106 

The CEV shall perform the maneuver sequence to return from Low Lunar Orbit (LLO) to Earth. 

CV0107 

The CEV shall calculate the maneuver targets for deorbit from LEO. 

CV0108 

The CEV shall calculate LLO navigation solutions for Trans-Earth Initiation (TEI) execution in less than 
12 hours in the event of loss of communications with Earth. 

CV0109 

The CEV shall perform trajectory correction maneuvers en route to Earth, returning from the Moon. 

CV0110 

The CEV shall independently provide navigation data of the CEV/CLV stack during ascent. 

CV0111 

The CEV shall independently provide navigation data of the integrated EDS/LSAM/CEV stack trajectory. 

CV0477 

The CEV shall independently provide navigation data of the integrated LSAM/CEV stack trajectory. 

CV0112 

The active CEV shall perform relative navigation for rendezvous, proximity operations and docking with 
the target vehicle. 

CV0121a 

The CEV shall perform automatic execution of rendezvous, proximity operations, and docking under 
nominal conditions. 

CV0124 

The CEV shall perform automatic execution of separation, proximity and departure operations. 

CV0118 

The CEV shall compute rendezvous maneuver targets while acting as the active vehicle during rendezvous. 

CV0119 

The CEV shall compute translational maneuver targets throughout all flight phases. 

CV0131 

The CEV shall perform rendezvous, approach proximity operations, and docking with the LSAM / EDS 
stack in LEO while acting as the active vehicle during rendezvous. 

CV0132 

The CEV shall perform contingency rendezvous and approach proximity operations with the LSAM in 
LLO with the unmanned CEV acting as the active vehicle. 

CV0471 

The CEV shall provide for remote control and proximity and docking operations from the LSAM- AS for the 
Lunar Sortie and Lunar Outpost DRMs. 

CV0133 

The CEV shall support approach proximity operations and docking with the LSAM functioning as the active 
chaser vehicle in Low Lunar Orbit. 

CV0134 

The CEV shall separate maneuver away from the unmanned LSAM Ascent Stage in LLO. 

CV0450 

The CEV shall separate and maneuver away from the unmanned LSAM in LLO prior to lunar descent. 

CV0135 

The CEV shall provide attitude control of the mated CEV/LS AM Ascent Stage configuration upon 
completion of docking operations in LLO. 

CV0136 

The CEV shall perform rendezvous, approach proximity operations, and docking with the ISS in LEO with 
the CEV acting as the active vehicle. 

CV0137 

The CEV shall separate and maneuver away from the ISS in LEO. 


GN&C ROLES AND RESPONSIBILITIES 


Figure 1 summarizes the events of interest for the lunar sortie Design Reference Mission (DRM) from launch 
through Earth entry in chronological order. The scenarios specific to the International Space Station (ISS) DRM 
LEO are also shown, interspersed appropriately. 
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Figure 1: Events of Interest Overview 

The following subsections provide an overview of the vehicles involved in the lunar sortie and ISS DRMs and a 
functional allocation of GN&C capabilities onboard the CEV based on the driving requirements and needs of the 
DRMs. 

Crew Exploration Vehicle (CEV) 

The CEV consists of the major elements shown in Figure 2. 



Service 

Module 

(SM) 


Command 

Module 


(CM) 


Spacecraft 

Adapter 

(SA) 



Figure 2: CEV Vehicle Components 



From left to right those four elements are Launch Abort System (LAS), Crew Module (CM), Service Module (SM), 
and Spacecraft Adapter (SA). The LAS supports ascent aborts and is jettisoned prior to Earth orbit insertion. The 
SA provides the interface to the CLV and is also jettisoned from the rest of CEV before Earth orbit insertion. Most 
of the time the CEV will comprise the CM and SM. The crew resides in the CM. The SM provides CEV power, via 
deployable solar arrays, and translation and attitude control authority, via Reaction Control System (RCS) thrusters 
and a single main engine. The SM is jettisoned from the CM shortly before reentry. 

Crew Launch Vehicle (CLV) 

The CLV is used to launch the CEV. The CLV comprises two stages and the avionics required to support launch as 
shown in Figure 3. The CEV avionics will monitor the launch and support aborts. 
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Figure 3: CLV Vehicle Components 
Lunar Surface Area Module (LSAM) 

The LSAM is the vehicle that will take crew to and from the lunar surface, conceptualized in Figure 4 as consisting 
of an Ascent Stage (LSAM-AS) and a Descent Stage (LSAM-DS). The complete LSAM is mated with the CEV in 
Earth orbit and remains mated en route to the Moon and in LLO. The LSAM’s RCS thrusters are responsible for 
mated LSAM/CEV stack control during translunar flight, including up to four scheduled Translational Correction 
Maneuvers (TCMs). The LSAM’s main engines are responsible for the three braking and circularization maneuvers 
required to perform Lunar Orbit Insertion (LOI), which puts the stack in a stable LLO. The LSAM separates from 
the CEV and descends to the lunar surface through use of its LSAM-DS. The LSAM-AS separates from the 
LSAM-DS in order to return the crew into LLO. The LSAM-AS will nominally rendezvous and dock with the 
uncrewed CEV for crew and cargo transfer; upon separation from the CEV, the uncrewed LSAM-AS performs the 
necessary maneuvers for self-disposal to the lunar surface. 
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Figure 4: LSAM Vehicle Components 

The LSAM, along with the EDS, is launched into Earth orbit atop the Cargo Launch Vehicle (CaLV), a launch 
vehicle different from the CEV’s CLV. 


Earth Departure Stage (EDS) 

The EDS is actually the upper stage of the CaLV and is responsible for inserting itself and its unpowered LSAM 
payload into LEO. The CEV launches separately atop the CLV to rendezvous and dock with the LS AM/EDS stack 
in LEO. The primary function of the EDS is to perform the Translunar Injection (TLI) maneuver for the mated 
EDS/LSAM/CEV stack conceptualized in Figure 5. The EDS fires its main engines to put the mated stack on a 
lunar transfer trajectory. Soon after the TLI maneuver is complete, the CEV/LSAM stack separates from the EDS 
under LSAM control, while the EDS performs the necessary maneuvers for safely disposing of itself on the lunar 
surface. The EDS contains all the necessary avionics required for LEO insertion, attitude control, TLI execution, 
and self-disposal. 
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Figure 5: EDS/LSAM/CEV Stack Components 
International Space Station (ISS) 

Early missions of the CEV will support docking to the ISS as shown in Figure 6. 



Figure 6: ISS/CEV Mated Configuration 
GN&C Functional Allocation 

This section shows which GN&C capabilities will be needed by the CEV in each of its key flight scenarios via a 
functional allocation table for each DRM. Figure 7 maps the targeting, navigation, guidance, and closed-loop flight 
control capabilities required of the CEV to support each flight event the ISS DRMs. The effector column denotes 
the scenarios and capacity in which the CEV’s effectors will be used. Since most scenarios will have multiple 
vehicles present, this allocation technique shows when the CEV is responsible for executing the primary targeting 
and GN&C flight software and effecting it. 

In each table a checkmark (V) denotes a capability that will be present and executing nominally during an event, and 
an Ab (for abort) denotes a capability that, while present, will execute only during an abort or contingency situation 
occurring in that event. To show additional traceability, the marked table cells contain footnotes pointing to the 
requirements of Table 1 that drive those capabilities if they explicitly exist. 
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Figure 7: CEV GN&C Functional Allocation - ISS DRM 


The marked cells are also color-coded in green and yellow. Green, which can be paired only with checkmarks, 
denotes a primary capability for flying the vehicle nominally. Yellow, which can be paired with either checkmarks 
or abort indicators, denotes a backup, contingency, or Situational Awareness (S.A.) capability. The yellow- 
checkmark combination means that the capability (e.g., navigation) is executing nominally but is serving only in a 
backup or S.A. capacity to the primary flight system. The yellow-abort combination means that the capability (e.g., 
guidance and control) executes only in response to an abort or contingency situation, potentially causing it to act as 
the driving flight system; e.g., an ascent abort causes a nominally passive CEV to depart from the CLV and become 
an actively flying vehicle on its own. 

To the left of each functional allocation table is a graphical depiction of the vehicles involved in that scenario to aid 
in visualizing the operations. All graphics are artist concepts, as used in Figure 1, and are commonly seen 
throughout other Cx documents. 

Figure 8 shows the analogous GN&C functional allocation for the lunar sortie DRM. 

Reference 3 contains the full analysis description of these functional allocations. 
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Figure 8: CEV GN&C Functional Allocation - Lunar Sortie 
NAVIGATION SENSORS 

The CEV uses a suite of inertial and relative sensors for determining its navigation state. Inertial sensors aid the 
GN&C system in the determination of the absolute state of the vehicle with respect to an inertial frame, typically 
fixed in either the Earth or the Moon. Relative sensors aid the GN&C system in the determination of the relative 
state of the vehicle with respect to a target vehicle-fixed frame [such as a rotating, Local Vertical/Local Horizontal 
(LVLH) frame during rendezvous and proximity operations] or a line-of-sight reference (such as the ground in the 
case of landing sensors). 

Figure 9 provides an overview of the CEV GN&C sensors described in this section with reference vendors, models, 
and numbers of units also detailed. The blue background groups the inertial sensors, the yellow background groups 
the relative sensors, and the green shows the overlap between the two; i.e., sensors that serve both purposes. 
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Figure 9: CEV GN&C Sensors 


Figure 10 shows the ranges of applicability for each of the relative sensors during Rendezvous, Proximity 
Operations, and Docking (RPOD). The chart also shows the ranges at which sensor data yields range data only; 
bearing data only; range and bearing data necessary for three Degree-of-Freedom (3 -DOF) state determination; and 
range, bearing, and relative attitude data necessary for 6-DOF state determination. 



0 


j RF Transponder (x2) 
Star Tracker (x3) 
LROC (xZ) 


0.3 ft 

(10 cm) 


I 


3.3 ft 

(1 m) 


inertial Sensors wf RPOD 
IIDAR (x2) 


Appl. 


i cation 


SROC (x2) 

33 ft 330 ft 3300 ft 5.4 NM 54 NM 540 NM 

(10 m) (100 m) (1km) (10 km) (100 km) (1000 km) 




docking 


final approach proxops 

Relative Distance 


V 

r© n d © zv'o u s 

A 

Note: Shuttle Ti (1 rev out) is 8 NM (1 5 km) 


□ 6 DOF information 

□ 3 DOF information 

□ Bearing information 

□ Range information 


Figure 10: Sensor Ranges of Applicability During RPOD 






This sensor suite is the reference design submitted for the CEV project’s CEV Reference Configuration 3 (CRC3). 
The Redundancy Management (RM) scheme planned is designed to meet the 2-Fault Tolerance (2FT) requirement 
in all flight phases and provide the greatest flexibility for navigation use. In addition to the sensors shown here, a 
radio frequency (RF) transponder book kept by the avionics system will be used for navigation when Global 
Positioning System (GPS) is not available. 

Global Positioning System (GPS) 

A GPS sensor system includes both the receiver and the antennas to provide onboard inertial position and velocity 
state vector updates during Earth ascent, LEO, and Earth entry phases of flight. Two antennas are required per 
receiver for near- full coverage of the GPS constellation of satellites (typically an upper and a lower antenna for 
seeing the upper and lower hemispheres of the sky). To alleviate signal losses in the cable runs between the 
antennas and the receivers, each antenna also requires a low-power 38-dB low-noise amplifier. 

The CRC3 reference design contains three General Dynamics Viceroy model GPS receivers with two antennas each 
(six total). 

Inertial Measurement Unit (IMU) 

The IMU contains 3 -axis strap-down-rate gyros to measure vehicle body attitude rates with respect to the inertial 
frame and 3 -axis accelerometers to measure vehicle body accelerations with respect to the inertial frame. This 
inertial data is required for onboard navigation to dead reckon (propagate) between (or in the absence of) position, 
velocity, and attitude state updates from the ground segment. 

The CRC3 reference design contains four Honeywell MIMU model IMUs. 

Star Tracker (ST) 

Through sighting on stars, the ST provides the highly accurate inertial attitude measurements required to update the 
IMU periodically throughout the mission via an IMU Align (the frequency of this update is a function of the IMU’s 
drift/performance characteristics). The primary output of the ST is an inertial-to-body attitude quaternion. 

In addition to inertial sensing, the ST also doubles as a rendezvous sensor via a Target Track feature that allows it to 
measure the relative bearing (azimuth and elevation) of the target vehicle (the EDS/LSAM stack, ISS, or LSAM- 
AS) at ranges far outside the field of view of the Automated Rendezvous and Docking (AR&D) sensors. During the 
far- field rendezvous [from 400 nautical miles (nmi) to 20 nmi, approximately], ST-measured bearing and 
transponder-measured range are the key measurements for determining the relative state of the vehicle. 

The CRC3 reference design contains three Goodrich HD 1005 model STs. This ST is one of the few that provides 
the required Target Track feature. Due to the desired mounting location of the STs on the CM, they must be 
thermally protected with Mylar blankets. 

Pressure Transducers 

Pressure transducers robustly provide highly accurate atmospheric pressure data (pressure/mean sea level altitude) 
that is critical for guidance and control during Earth entry, including chute deployment and landing. Accuracy and 
data availability in the altitude channel is superior to that measured and maintained by the GPS and IMU, hence the 
design decision to include this sensor in the suite. 

The CRC3 reference design contains three Honeywell LG- 1237 Smart PT model pressure transducers. 

Light Detection and Ranging (LIDAR) 

The LIDAR sensor contains a laser that provides time-of-fhght-based relative range, bearing, and attitude 
measurements during RPOD flight phases via direct signal returns from target-mounted retroreflectors. The LIDAR 



measurements support manual piloting, remote control, and AR&D operations. LIDAR functionality is independent 
of orbital lighting once the target is initially acquired. 


The CRC3 reference design contains two MDA LIDARs that have flight test heritage onboard the XSS-1 1 satellite. 

Long-range Optical Camera (LROC) 

The LROC capabilities serve two GN&C functions. Primarily, the LROC provides imaging required to perform 
Celestial Navigation (CelNav) during both cislunar transit and LLO to give the vehicle an onboard navigation 
capability while outside the influence of GPS. While cislunar, the LROC provides an image of a star field 
observation, and the CelNav algorithm uses the ST-provided inertial attitude to reduce the star image back into the 
inertial frame to compute a state. While in LLO, the LROC can track the lunar surface and, via surface feature 
recognition and CelNav algorithms, determine an inertial state based on bearing measurements. The surface feature 
tracking algorithm may also be able to use apparent diameter (from the LROC image) as a range measurement to 
further aid state determination. 

During rendezvous operations, the LROC provides relative range and bearing measurements to augment similar 
measurements taken by the other AR&D sensors. 

The CRC3 reference design contains two Altasens LROCs. Each LROC consists of a single 2.0-megapixel optical 
sensor unit and a separate avionics box containing a video processing unit, a communications interface, and timing 
and control electronics. 

Short-range Optical Camera (SROC) 

Processed images of the target vehicle/docking target array from the SROC provide relative range, bearing, and 
attitude measurement data during RPOD operations to support manual piloting, remote control, and AR&D 
operations. In addition to being a data sensor, the SROC provides motion imagery for the onboard crew, the remote 
vehicle crew, and the Mission Planning, Training, and Flight Operations (MPTFO) elements. SROC use is limited 
to orbital daylight or while within range of the illuminated target array on target vehicle. The illumination of the 
target array is achieved via a separate illuminator/docking light comprising light emitting diodes (LEDs) that will 
provide target illumination out to approximately 650 feet (200 meters). 

The CRC3 reference design contains two Altasens SROCs. Each SROC unit consists of three 2.0-megapixel optical 
sensor units and a separate avionics box to handle the multicamera multiplexing, video processing, timing, and 
control electronics and communications required for the optical triad. The three optical sensors are like those of the 
LROC, but they are bundled together in a single assembly. The orientation of each of the three cameras with respect 
to the assembly can be configured premission to the optimal geometry required for RPOD operations. While the 
triad architecture of cameras for a single SROC provides additional levels of capability and redundancy, the SROC 
by itself is still a zero-fault-tolerant sensor by virtue of its single avionics box; therefore, two SROCs are still needed 
in the reference design for system redundancy. 

Radio Frequency (RF) Transponder 

These transponders are actually the same ones used by the communications (comm) system and, therefore, bookkept 
by the comm system. Their dual role in the GN&C arena, however, is significant enough to warrant discussion here. 
The transponders are the conduit for receiving ground-tracked, inertial position, and velocity (not attitude) state 
uplinks from MPTFO elements. In addition, the transponders provide Doppler relative-range and range-rate 
measurement during rendezvous operations (out to 400 nmi) through pinging a sister transponder on the target 
vehicle. 


Landing Sensors 

The CM will use a range-above-ground relative sensor to provide accurate and precise altitude information just prior 
to landing. This information will be used to trigger a capsule landing orientation (roll) maneuver aligning the crew 
with the horizontal velocity at touchdown, if desired, and to trigger the firing of CM-mounted retrorocket jets 



designed to minimize vertical velocity and impact loads at touchdown. The baselined sensor for this function is the 
MSP ’98 Landing Radar by Honeywell, a 4-beam radar altimeter originally adapted for use on a Mars lander that 
can provide altitude and limited horizontal velocity information for an Earth landing without ambient lighting. Two 
redundant radar avionics units will be integrated into the CM; both are connected to a single antenna cluster of four 
integrated antennas oriented down. Antennas have a very high reliability relative to the radar avionics. Like the 
retrolanding jets, use of this radar will require release of the CM heat shield because it is unlikely that it will be able 
to work effectively, sending and receiving pulses, through the material selected for the heat shield. An estimate of 
horizontal velocity as made available by this sensor will also be used to determine if the CM is landing on a modest 
slope and potentially to adjust the crewmembers’ impact orientation appropriately. 

The GN&C logic and systems will communicate with the radar altimeter units via a software Subsystem Operating 
Program (SOP) as described in the flight software subsection and will monitor the system health of each unit, send 
configuration commands to each, and receive range (altitude) and estimated horizontal velocity from the active radar 
system. 

Backup Sensors 

As part of the emergency entry system design, the CM may also use backup pressure altitude sensors, independent 
of the flight computer and enabled by manual command, for triggering critical landing system events, specifically 
nose cone release, mortar firings for drogue and main chute deployment, and heat shield release. Otherwise an 
emergency entry system backup for triggering chute deployment could simply involve manual switch throws. 

Other possible backup sensors to support an emergency entry system landing could include sending one of the 
IMU’s raw outputs to a separate attitude display that a crew (or flight computer that has lost its absolute navigation 
orientation) could use to null out attitude rates if all primary attitude navigation is lost. An automated system that 
has lost its navigation state could also use an emergency backup 3 -axis accelerometer package to sense deceleration 
just after entry interface and orient the capsule appropriately (heat shield first) prior to commanding a ballistic spin- 
up. 

An even simpler approach for a possible emergency entry system could involve placing some attitude reference 
marks on the windows that the crew could use to orient the capsule, via manual RCS commands, prior to entry if all 
flight computers fail. This approach uses very simple techniques available to both Apollo and Soyuz. 

Other capabilities are under consideration as part of an Entry Emergency Mode capability, including (1) a simple 
backup flight computer with a significantly reduced instruction set (just sufficient to orient the capsule, spin it up, 
and deploy chutes) or (2) similar instructions existing in a safe mode software configuration for a rebooted primary 
computer after a total computer failure. 

Sensor Locations 

Figures 11, 12, and 13 show some conceptual layouts of where key inertial and relative navigation sensors could be 
installed on the CEV in order to achieve the required fields of view and lines of sight during the DRMs. 

One of the key placement changes made during the CRC3 design cycle was the reorientation of ST 3 so that it points 
perpendicular to the capsule’s longitudinal (X-body) axis rather than perpendicular to the capsule sidewall as STs 1 
and 2 do. This reorientation will allow ST 3 to see stars while the CEV is in Orbit Maintenance mode in LLO, 
holding an LVLH attitude pointing radially down at the lunar surface; this alleviates concerns that the fields of view 
of STs 1 and 2 will be obscured by the Moon. 

Although not explicitly shown in the figures, another key placement constraint the GN&C team imposed on the 
layout was the placement of all IMUs and STs on a common structure to serve as a navigation base to minimize 
alignment errors between those sensors due to vehicle flex caused by thermal and vibration effects. 
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Figure 11: Sensor Locations (Centerline View) 



Figure 12: Sensor Locations (View 1) 





Figure 13: Sensor Locations (View 2) 

REDUNDANCY MANAGEMENT 

Figure 14 shows the block diagram for a candidate navigation architecture. This scheme provides a mechanism to 
meet the RM and FT objectives of all stages: ascent, entry, LEO, lunar transit, and LLO. Four strings of navigation 
states are maintained using four identical filters, one of which is configured as an IMU-only propagator. All sensors 
can be cross-strapped to all filters. Each filter configuration and the desirability of its filtered state output for use are 
configurable via initialization load (I-load) and flight mode settings. These I-loads would determine, per flight 
phase, how many filtered state are maintained, which sensors are used, and what sensor outputs are sent to which 
filters. Fault Detection, Isolation, and Recovery (FDIR) and sensor selection occur before filter input, and one set of 
sensors is preselected for insertion into a prime designated filter. The prime filter gets the best measurements 
available based on which selection scheme is used; e.g., weighted average, midvalue select. Two other strings 
maintain the remaining unique sensors; a quality rating relative to the prime string can be assessed, if desired. One 
IMU is used as a clean propagator string based on the best performing IMU data with no other data inputs other than 
periodic prime state updates. Flight phase dictates the number of filter strings to be considered (1, 2, 3, or 4) for 
prime selection; however, all are maintained. The strings can be monitored by the ground. Strings that are not used 
for the navigation state during some phases can be used for real-time testing of other redundancy modes for future 
upgrades. All strings can be reinitialized with the navigation state at any time (similar to ISS’s scheme). If a sensor 
fails, the prime string will automatically select another one; the bad sensor will be removed, and a default sensor will 
be cross-strapped to the third string. Logic for the subsequent recovery and reintegration of a failed sensor will 
reside in the FDIR. In this case, entry can have the choice of eliminating the third string and incorporating the 
fourth (IMU-only propagator) for voting or keeping a cross-strapped string in the voting loop and using the fourth 
string as a quality check on the three voted strings. The prime string could be designed to be either sensor 
dependent (i.e., all data from the selected sensor goes to that string) or variable independent (i.e., best values of each 
variable go to the prime regardless of sensor). 
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Figure 14: CEV Navigation Sensor Redundancy Management Architecture 

During ascent all four strings are initialized from clean IMU measurements, and their solutions would be propagated 
solutions without other sensor measurements. The navigation state would be output based on the prime string, 
which could be set to take best IMU measurements of all four IMUs or just a specific selected one. Prior to the 
abort modes, the sensor data would be allowed into the filters after passing through FDIR and sensor selection. 

During orbit, prox-ops, docking, LEO, and LLO, each sensor could be turned on or off or mapped to a different 
string with the best measurements going to the prime; the other strings are maintained as a quality check on the 
system. Since the prime is always used as the navigation state during these phases, the concern that switching 
between filters causes discontinuities (i.e., data jumps) is not an issue. Each string could be monitored by the 
ground, and as faults are detected the degraded or failed sensors could be removed from the strings and replaced, via 
software reconfiguration commands, by other valid sensors. Reconfiguration could be done either automatically or 
manually by the ground or crew, as required. For LROC, SROC, and LIDAR, each unit could be reconfigured to a 
different filter string, with the prime selecting the best values based on the preselection criteria. If only one of each 
sensor type is powered, the other filter strings could be used as straight propagators; alternatively those sensors 
could also be cross- strapped to the other filters for that flight phase. The selection filter would also allow for a 
selected navigation state to be provided back to the filter strings for reinitialization and resynchronization. The 
selection criteria possibilities are limitless and could be tested in real time if all four filters are always running. 

For entry, having all necessary redundant sensors powered on with four navigation filters and a selection algorithm 
for determining the best state solution is an excellent redundant system. The fourth IMU-only/propagator string 
would be updated just prior to entry and would propagate to the ground. One string could completely diverge, and 
the performance of the other three strings would still meet the landing accuracy objectives. FDIR and sensor 
selection should pick up any known anomalies so that the prime filter can provide the best solution all the way to 
ground; the other three strings provide verification that the prime has not diverged. Should the prime diverge, the 
selection filter would select another filter string. In the event a second string fails, the IMU-propagated solution 
would complete the task, albeit with an accuracy that may impact the landing accuracy objectives. 


The primary advantage of this design is that it gives the most flexibility; sensor/filter reconfiguration can be made 
on the fly if needed. Although this flexibility allows numerous sensor/filter configuration permutations, only the 
ones planned for nominal and contingency flight operations would require certification. If additional strings and/or 
functionality is added in later CEV system upgrades, those performance permutations can be verified using flight 
data from previous missions. The I-loadable, cross-strapped nature of the design would, therefore, foster the ability 
to improve navigation accuracy in future missions as more flight experience and flight data are accumulated. Such 
flexibility and ease of future adaptation, however, come at the expense of a complex implementation. 

Reference 4 contains the full analysis description of this and other candidate RM schemes and the trades involved. 

GN&C FLIGHT SOFTWARE ARCHITECTURE 

Figure 15 shows a functional block diagram overview of the CEV GN&C system and its interfaces to its own 
sensors, effectors, and external Cx elements. The central block in the diagram functionally represents the Flight 
Critical Processor (FCP) on which the avionics and GN&C FSW resides and executes. 
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Figure 15: CEV GN&C Software Architecture 

This section describes the software elements internal to the CEV FCP that are relevant to FD and GN&C. The 
classical system elements of top-level avionics Vehicle Executive FSW and FD core GN&C FSW are both 
represented. In response to the CARD and CEV SRD requirements for automated and autonomous FD events and 
responses, a new class of software subsystem, the Onboard Trajectory Manager (OTM), has been envisioned. The 
OTM is the FD slice of a vehicle-wide, systems-wide avionics manager known as the Vehicle Systems Manager 
(VSM). Although the VSM reference architecture is concurrently being designed by the CEV avionics group, the 
FD discipline understands VSM to be the top-level avionics application that schedules and executes all FCP 




applications, including its own avionics Vehicle Executive and the two major FD components, the OTM and core 
GN&C. The VSM has integrated oversight responsibility of all of the vehicle’s subsystems. This section explores 
some of the key details of the OTM, the Vehicle Executive, the GN&C Executive, and the GN&C sensor and 
effector SOPs. Additional details regarding the core GN&C blocks themselves, flight-phase dependent algorithms, 
and key engineering parameters flowing between them can be found in Reference 5. 

Onboard Trajectory Manager (OTM) 

The OTM is essentially a trajectory planning application that contains three main subsystem components: the 
Onboard Abort Executive (OAE), the Onboard Nominal Executive (ONE), and the FD Task List Selector (FDTLS). 
The OTM can receive such external inputs as activity lists and mode commands from the ground and crew systems, 
internal inputs from its own subsystems (OAE, ONE, and FDTLS), and navigation state and status feedback from 
core GN&C. The OTM’s primary output is an FD Task List, which is simply a queue of FD tasks intended to be 
executed in sequence by core GN&C. The task data may include such various trajectory parameters as vehicle 
position, velocity, attitude, and attitude rates. The OTM and core GN&C exchange information via the Vehicle 
Executive. 

The OAE is intended to plan and manage such automated abort trajectories as ascent aborts. The ONE is intended to 
plan and manage automated nominal trajectories; e.g., during AR&D operations. Both the OAE and ONE output 
FD Task Lists to the OTM’s FDTLS based on their planning algorithms and operational flight rules and constraints. 
The FDTLS is then responsible for prioritizing all provided FD Task Lists, allowing for override considerations and 
factoring in cross-cutting systems issues from VSM, to output a single FD Task List to the Vehicle Executive. 
Cross-cutting systems issues may include resolving power resource contentions, blowing pyrotechnic devices, 
activating buses, and stirring propellant tanks. A specific example is the proverbial duck-in-the- windshield scenario 
in which the vehicle hits a duck during ascent, thus causing a life-critical cabin leak worthy of mission abort. Being 
a life-support systems problem, the FD subsystems of OAE, ONE, and core GN&C would be oblivious to the 
problem and press onward with the mission as if nothing were wrong. VSM, however, would be aware of the 
problem and could command an ascent abort to the OTM’s FDTLS, which would take priority and result in a new 
abort-related FD Task List being sent to the Vehicle Executive for execution by core GN&C. 

As unexpected FD scenarios or contingencies arise that would impact the FD Task List, which would most likely be 
reworked and/or reordered by the OAE, the OTM can simply pass the updates to the Vehicle Executive for 
execution. 

A prototype OAE application has been developed to support ascent abort trade studies under FD Task Description 
Sheet (TDS) 04-012, Integrated Ascent and Abort Characterization and Sensitivity Study (Reference 6). More 
details on its internal architecture and functionality can be found there. 

Vehicle Executive 

The Vehicle Executive subsystem is envisioned as the avionics VSM engine responsible for executing all of the 
vehicle’s subsystem executives; e.g., GN&C, power, environmental control, life support. FD data that is required by 
OTM and GN&C is brokered through the Vehicle Executive. The Vehicle Executive receives GN&C state and 
health data from the GN&C Executive to relay to the OTM; it also receives prioritized FD Tasks Lists from the 
OTM (courtesy of its FDTLS) with which to command the GN&C Executive. Rather than simply passing the entire 
FD Task List to the GN&C Executive, the Vehicle Executive doles out the task commands contained in the FD Task 
List, task by task in real time. Task commands may be simple mode commands or more complex commands with 
argument data; e.g., a commanded attitude or velocity. This design allows the GN&C Executive to deal with only 
one command at a time rather than having to take in the entire FD Task List at once and dole it out internally. This 
approach leverages a queuing capability envisioned already to be part of the Vehicle Executive, thus removing the 
requirement from GN&C and simplifying the integrated design. 

The Vehicle Executive is also responsible for gathering all the input data required by core GN&C (e.g., sensor data 
messages, system state data, commands from the FD Task List) and providing it in a time-homogenous fashion. 
Likewise, it is also responsible for gathering output data from core GN&C (e.g., effector command data, vehicle 
navigation- state data) and relaying it to the proper hardware and software users in a time-homogenous fashion. 



The Vehicle Executive contains vehicle mode transition rules for determining when to advance from one task to the 
next in the FD Task List based on key GN&C task-completion data from the GN&C Executive; e.g., timers, key 
altitudes and navigation states, events, submode completion flags. As such, the Vehicle Executive is responsible for 
coordinating and executing the flight phase and flight segment transitions across the vehicle’s subsystem. The 
driver for handling phase, segment, and mode transitions in the Vehicle Executive rather than the GN&C Executive 
is that these transitions are of interest and consequence to the entire vehicle and not just GN&C. 

GN&C Executive 

The GN&C Executive is the interface for all Inputs and Outputs (I/O) between core GN&C (which includes sensor 
and effector SOPs) and the external world (which includes the sensor effector hardware). 

Figure 15 shows sensor and effector I/O in a functional sense via the red arrows to denote that the data will actually 
pass between the GN&C Executive and the hardware via the Vehicle Executive. The Vehicle Executive serves as 
the mechanism for getting the data into the proper avionics common data areas (CD As) for driving the hardware 
since avionics will be responsible for all I/O system services; e.g., 1553 data buses, RS-422, 1394a. 

When the GN&C Executive receives the external world’s inputs, it is responsible for checking and enforcing the 
validity of commanded mode transitions to ensure robustness, correctness, and consistency within GN&C to protect 
against instances of invalid FD Task List commands. As discussed in the Vehicle Executive section, the GN&C 
Executive handles only one task command at a time to simplify interfacing and testing. The GN&C Executive is 
responsible for setting the submodes of its individual components and coordinating and brokering data between 
them, which includes sensor SOPs, targeting, navigation, guidance, control, and effector SOPs. An example of such 
data brokering is mapping navigation outputs to guidance inputs. Part of the GN&C Executive’s data brokering 
responsibilities is ensuring the time homogeneity of the overall GN&C outputs to the Vehicle Executive just as the 
Vehicle Executive ensured the inputs. 

Figure 16 shows a functional flow of key data between the GN&C subsystems under the purview of the GN&C 
Executive. 



Figure 16: CEV Core GN&C Internal Interactions 

The GN&C Executive executes its GN&C subsystems based on flight phase, segment, and mode data received from 
the FD Task List command and the corresponding submodes of each GN&C subsystem. Subsystem execution may 
be a function of cyclic rate group; e.g., guidance subsystems may run at a lower frequency while flight control 










subsystems run at a higher frequency. Rate group requirements, while immature at this point in the design process, 
may require multiple GN&C Executives running as separate tasks in the avionics data management system. 

GN&C Subsystem Operating Programs (SOPs) 

Each GN&C sensor and effector type has its own software subsystem dedicated to receiving raw data from the 
hardware; processing it to extract and generate the engineering measurement, health, and status information to pass 
on to the core GN&C algorithms; and relaying initialization and moding commands to the hardware from GN&C. 
Such a software subsystem is termed a SOP, which is the heritage term from the shuttle’s software architecture 
implementation. 

Each SOP receives the data from all redundant hardware units of a similar type (e.g., a GPS SOP receives the GPS 
raw data from each of the three GPS units) and performs whatever FDIR functions may be required to assess the 
health of the hardware and react to anomalies where action can be taken to ensure hardware and subsystem integrity 
and safety. The FDIR may include such functions as reasonableness checks to ensure data integrity and selection 
algorithms to quantify and qualify the performance of each redundant hardware unit; e.g., to determine which unit is 
performing best and should be designated prime. The selection algorithm functionality is key to a SOP’s ability to 
support RM. Reference 4 describes the recommended reference design for how a sensor SOP’s fault tolerance, 
FDIR, and RM capabilities interact with core GN&C’s navigation filters and navigation state selection algorithms. 

GN&C SOPs are considered part of the core GN&C system but use avionics (CD A) and hardware interfacing 
protocols (e.g., MIL-STD-1553, RS-232) for brokering the data between the GN&C FSW and the hardware. In 
other words, the SOP would not directly communicate with the hardware interface for data receipt and commanding; 
the SOP would communicate through the GN&C Executive’s software interface to the avionics CDA mechanisms 
by way of the Vehicle Executive and/or VSM in order for avionics to do the direct communication with hardware; 
e.g., in the case of a 1553 hardware interface, GN&C would not do any direct 1553 bus commanding but would 
relay the appropriately packed messages to avionics resources for avionics to schedule and control the 1553 bus 
commanding. 

CONCLUSION 

The reference GN&C architecture summarized in this document addresses the driving requirements, the GN&C 
roles and responsibilities of the CEV, its navigation sensor suite and redundancy management scheme, and a 
candidate flight software architecture. This reference design was done independently by NASA during the CEV 
prime contractor downselect period, Phase 1 , in an effort to make NASA smarter customers after downselect and 
good stewards of the CEV requirements. The effort behind this reference design will help NASA understand the 
design trades and issues of the requirements when merging with the prime contractor and overseeing development of 
the CEV. 
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